Web Services
The term Web services is commonly used in reference to a modular collection of web-protocol based software applications that can be mixed and matched to provide business functionality through an internet connection.
With Web Services, information sources become components that you can use, re-use, mix, and match to enhance Internet and intranet applications ranging from a simple currency converter, stock quotes, or dictionary to an integrated, portal based travel planner, procurement workflow system, or consolidated purchase processes across multiple sites. Each is built upon an architecture that can be illustrated as a stack of layers as shown in FIG. 1.
Each vendor, standards organization, or marketing research firm defines Web Services in a slightly different way. Gartner, for instance, defines Web Services as “loosely coupled software components that interact with one another dynamically via standard Internet technologies.” Forrester Research takes a more open approach to Web Services as “automated connections between people, systems and applications that expose elements of business functionality as a software service and create new business value.”
Although there are a variety of Web Services architectures, Web Services, at a basic level, can be considered a universal client-server architecture that allows disparate systems to communicate with each other without using proprietary client libraries.
An advantage of the Web services architecture is that it simplifies the development process typically associated with client/server applications by effectively eliminating code dependencies between client and server and the server interface information is disclosed to the client via a configuration file encoded in a standard format Doing so allows the server to publish a single file for all target client platforms.
Unfortunately deployment of Web services is hampered by the problem of providing secured access to these services, and describing policies governing how Web services and their client applications interact.
Current security implementations and mechanisms introduce brittleness and tight coupling between the client applications and the Web service, leading to solutions that are not easily reusable, or that require expensive re-development when security policies or agreements change. Furthermore, current platform vendors have not considered how both sides of Web services transactions (provider and consumer) should be coordinated.
Service Oriented Architecture (SOA)
To support these Web-Services in the Internet, a new architecture was defined, SOA, the Service Oriented Architecture. This new architecture describes how Web-Services may be found by users, how a potential user can access such Web-Services, and a language describing the interfaces to these services.
The communication protocol for these Web-Services is also defined by a new protocol, called Simple Object Access Protocol (SOAP).
SOAP is a way for a program running in one kind of operating system to communicate with a program in the same or another kind of an operating system by using preferably the World Wide Web's Hypertext Transfer Protocol (HTTP) and its eXtensible Markup Language (XML) as the mechanisms for information exchange. Since Web protocols are installed and available for use by all major operating system platforms, HTTP and XML provide an already available solution to the problem of how programs running under different operating systems in a network can communicate with each other.
SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one computer can call a program in another computer and pass it information. It also specifies how the called program can return a response.
One of the main principles of an SOA is the concept of loose coupling. In a loosely coupled system, connections and interactions between various components are flexible enough so that changes in the interface of one component will not lead to a breakdown of another component. In order to enable loose coupling, three main Web services standards have evolved, all based on the fundamental XML standard. Each of these three standards are illustrated as a stack of layers in FIG. 1 and are:
SOAP. As mentioned above SOAP is XML based messaging standard, defining an envelope element as a container for a header element and a body element, in a request-response interaction model. Using XML on the wire for messaging hides technology choices from both ends of the conversation.
WSDL (Web Services Description Language). An XML based Interface Definition Language (IDL) similar to other IDLs defined for example in the CORBA architecture. A WSDL document described the functional aspects of a service, such as the format of the input and output messages, and the URL to which the SOAP request should be sent to invoke the service.
UDDI (Universal Description, Discovery and Integration). An XML and SOAP based API specifications for service description publication and discovery. A UDDI server acts as a registry for Web services, and provides a mechanism to locate services and retrieve their interfaces.
While the platform and tools vendors have made available a variety of technologies to handle the layers in the Web services stack (such as SOAP and WSDL toolkits and UDDI implementations), the bulk of the effort has been directed to the provisioning, of the various Web services, with the creation of deployment environments and management tools.
Unfortunately, deployment of Web services is hampered by the problem of providing secured access to these services, and describing policies governing how Web services and their client applications interact.
For example, current security implementations and mechanisms introduce brittleness and tight coupling between the client applications and the Web service, leading to solutions that are not easily reusable, or that require expensive re-development when security policies or agreements change. Furthermore, current platform vendors have not considered how both sides of Web services transactions (provider and consumer) should be coordinated.
Current technologies address security issues, by providing two kinds of solutions, both geared mainly to Web service providers. These include tools for developers, making security a software development problem and static firewall solutions that perpetuate the brittleness of tight coupling between systems. Very little has been done to address the more practical, real-world, aspects of securing, coordinating and customizing Web services in a dynamically at run-time, especially in an environment where typically a Web service will have multiple consumers with varying security requirements and policies.
Technologies integrating all layers of the Web services stack (including SOAP, WSDL and UDDI) for both service provider and consumer are missing. This lack of solutions makes it difficult for many organizations to justify a full and public adoption of Web services technology, regardless of its eventual promise.
Tight Binding of Services to Requester
In FIG. 2, there is shown schematically, the roles and sequence of events in an SOA. A Service Provider publishes a description of its service to a Services Broker, typically a UDDI server or node which operates as a repository. This service description also typically includes a WSDL document. Before the client can request the service it need to find the provider. Upon request, the service broker (UDDI node) returns a document that allows the client to locate the particular providers interface then bind to the provider. It then invokes the service through the bindings described in the interface. All interactions between the three entities are typically SOAP requests.
One of the limitations of this architecture occurs when issues of security and policy are involved. In typical real world scenarios, services that are provided between business entities, whether within the departments of a particular organization, or between business partners, are not anonymous. Instead, they are governed with sometimes strict security policies and maybe even different usage and Quality of Service (QoS) policies and agreements.
Despite recent advances in tools and infrastructure, the state-of-the-art in Web services security remains laborious and prone to error. Security best practices are ill defined. What little implementation exists is littered throughout the Web services stack, appearing in the transport layer, at the application server, and in every individual Web service protocol and implementation. This creates a number of vulnerabilities and multiple points of failure that conspire to complicate the developer's and the administrator's jobs. Once an administrator deploys a service, security becomes instantly entrenched and difficult to manage. Any change an organization makes to its security policy, any alteration made to signatures, encryption, or even server location, seems to necessitate a costly new development effort, both on the server side and on the client side. These issues combine to make solutions that are simply not reusable.
Implementing security policies into the code of the Web service is undesirable for many reasons. Web service and XML security is a complex matter and very error prone, especially for non-expert developers, and will add a large amount of time and expense to any Web services deployment project; policies can and will change over time, leading to more time and expense and possibility of error any time the code base has to be modified; and finally, as partners are added or removed, or their individual policies are modified, the Web service code, with the security code embedded in it, will become extremely difficult, if not impossible, to manage.
But even if all those obstacle were surmountable, a major issue remains: by implementing complex, but necessary, policies on the Web service side, the burden of implementing your security is placed on the client application. This is a very serious responsibility, and in many cases consumers of the Web service are not up to the challenge of implementing the required security. More importantly, however, any change in policies on service side will need to be mirrored on the client side, in order for the system to remain operational.
There remains a need for a solution that both manages and coordinates security, end-to-end across a Web Services integration lifecycle and which is a centrally administrable, standards-based solution that restores fine-grained security control and visibility to IT managers at the Web services application layer.